Presentation of critical patient data

ABSTRACT

A computer-implemented patient information presentation method is disclosed. The method includes extracting, from records maintained for a patient under care in a healthcare facility, a subset of data points for that patient that are determined to represent data points of highest relevance to a subset of potential caregivers for the patient. The method also includes grouping the subset of data points into a plurality of groups based on a determined relatedness among data points in each of the plurality of groups, and generating a display for presentation to a caregiver that shows at least some of the subset of data points arranged in the groups.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/697,861 to Ognjen Gajic et al., entitled “Presentation of CriticalPatient Data,” and filed Feb. 1, 2010, which claims priority to U.S.Provisional Patent Application Ser. No. 61/148,953 to Ognjen Gajic etal., entitled “Presentation of Critical Patient Data,” and filed Jan.31, 2009, the contents of each are incorporated herein by reference.

TECHNICAL FIELD

This document relates to computer-based systems and techniques forproviding information about the clinical status of a patient, such as apatient in an intensive care unit (ICU), and of making clinicaldecisions for treating the patient.

BACKGROUND

The care of critically ill patients generates vast quantities ofclinical data. These data are processed by an ICU team and are the basisof subsequent medical decision making. Data overload is a phenomenonwhereby the significance of data (signal) is lost within an overwhelmingquantity of insignificant data (noise). The quantities of data generatedin the ICU can, at times, overwhelm a physician's personal capacity toidentify and then process relevant data. This may lead to errors ofclinical judgment or delays in the delivery of time sensitiveinterventions.

SUMMARY

This document describes systems and techniques that may be used toprovide information about patient status, such as an ICU patient, tomembers of a medical team. ICU's are busy places that generate a lot ofpatient data, and caregivers such as physicians may easily becomeoverwhelmed with information. The systems and techniques described hereaim to identify the most important data, to group it in manners that areintuitive for a caregiver, and to display or otherwise present theinformation in an efficient and effective manner to the caregiver. Theprocess of identifying the most important data may occur by filteringall of the data being gathered on a patient to isolate data relating tofeatures of the patient that expert physicians most often review forpatients in a situation like the particular monitored patient. Data of aparticular type may then be gathered together into groups, such as datarelating to a particular body organ or function. The data groups maythen be presented graphically and textually in a manner that improvesthe ability of a caregiver to quickly understand the current and paststate of a patient and to make clinical decisions that will benefit thepatient.

In certain implementations, such systems and technique may provide oneor more advantages. For example, patient care and safety may be improvedwhen a caregiver can make better medical judgments from well-selectedand well-formatted information. Also, caregivers may be able to provideadditional care if they are able to discern a patient's overall statusmore quickly because they have been presented relevant data in anunderstandable manner. Moreover, caregiver fatigue may be lessened andcaregiver satisfaction improved when useful and pleasing systems areprovided to caregivers, and caregivers are not forced to struggle tocomplete tasks that should be conducted for them, such as identifyingthe most relevant data for a patient.

In one implementation, a computer-implemented information presentationmethod is disclosed. The method comprises extracting, from recordsmaintained for a patient under care in a healthcare facility, a subsetof data points for that patient that are determined to represent datapoints of highest relevance to a subset of potential caregivers for thepatient. The method also comprises grouping the subset of data pointsinto a plurality of groups based on a determined relatedness among datapoints in each of the plurality of groups, and generating a display forpresentation to a caregiver that shows at least some of the subset ofdata points arranged in the groups. The method can also includeidentifying a plurality of subset groups of the data points, where eachof the plurality of subset groups is directed to a particular caregiverlevel that differs from others of the plurality of subset groups. Thesubset groups can be directed to different job titles of caregivers.

In some aspects, the method also includes detecting the presence of anelectronic caregiver beacon in proximity to a patient monitor,determining a caregiver level corresponding to a caregiver associatedwith the beacon, and displaying a subset of data points directed to thedetermined caregiver level corresponding to the caregiver. The caregiverbeacon can comprise an identification badge or biometric indicator. Inanother aspect, the records are stored in a plurality of separate andindependent data stores, including a real time patient condition datastore and an electronic medical record data store. Also, the subset ofdata points can be selected as data points having a highest frequency ofreliance by experienced caregivers in a group of caregivers having acommon job categorization.

The method can also comprise detecting one or more indicia of organfailure and changing a display mode presented to the caregiver toprovide information targeted to the organ failure and to deprecate otherinformation previously displayed on a display. In addition, the methodcan comprise performing an identification of a caregiver in proximity toa patient monitor and generating the display for presentation to thecaregiver according to a custom layout for the caregiver. The method canalso comprise detecting the task that the user is undertaking andreconfiguring the display to optimize the performance of that task (taskspecific modules—sepsis and checklist are given for illustrativepurposes)

In another implementation, a computing system is disclosed thatcomprises a patient video monitor, one or more processors, memory, andone or more programs. The one or more programs are stored in the memoryand are configured to be executed by the one or more processors. Theprograms include instructions for extracting, from records maintainedfor a patient under care in a healthcare facility, a subset of datapoints for that patient that are determined to represent data points ofhighest relevance to a subset of potential caregivers for the patient.The programs also include instructions for grouping the subset of datapoints into a plurality of groups based on a determined relatednessamong data points in each of the plurality of groups, and instructionsfor generating a display for presentation to a caregiver that shows atleast some of the subset of data points arranged in the groups.

In yet another implementation, a computer-implemented patientinformation presentation system is disclosed. The system comprises adata extractor operating on a computer processor system programmed toanalyze a plurality of independent data sources to obtain a subset ofdata about a patient, from the data sources, using heuristic rulesdirected to patient data points of highest relevance to a subset ofpotential caregivers for the patient. The system also comprises a datagrouper operating on the computer processor system, and an electronicpatient monitor to receive display data from the computer processorsystem and to display group patient information for at least some of thesubset of data

The details of one or more embodiments are set forth in the accompanyingdrawings and the description below. Other features and advantages willbe apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a conceptual flow diagram showing the processing of patientrelated ICU information into a clinical decision to aid the patient.

FIG. 2 is a block diagram showing various patient-related data sources.

FIGS. 3A to 3H show example displays that may be shown to caregivers inan ICU setting.

FIG. 4 is a flow chart showing actions for processing and presentingpatient-related ICU information.

FIG. 5 shows data representing a survey of physician preferences fordata points in an ICU setting.

FIG. 6 is a graph showing variance between attending physicians andother caregivers in terms of preference for particular ICU-related datapoints.

FIG. 7 shows an example screen shot, or display, of a patient monitoringinteractive checklist.

FIGS. 8A and 8B are two portions of a table of example values for thepatient monitoring interactive checklist of FIG. 7

FIG. 9 is a block diagram of a patient monitoring system.

FIG. 10 is a schematic diagram of a computing device and a portablecomputing device that may be used to carry out the actions described inthis document.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

This document describes systems and techniques for identifying data thatis most likely to lead to positive patient outcomes, and for presentingthat data to caregivers in a manner that the caregivers can produce thepositive outcomes. In one implementation, the techniques here involveacute warning and response valuation (AWARE), which may be used toincrease the signal-to-noise ratio for data in a setting such as an ICU.The AWARE system screens or filters data that may be found throughout ahealthcare system, from immediate information about a patient, such asblood pressure, to medical record information, to medical historyinformation.

After the screening or filtering, the relevant data is bundled intodiscrete “information packages” which are then formatted and presentedto a caregiver. Information packages contain the most relevant data andfacilitate real time clinical decision making and care delivery. TheAWARE interface gathers highly valued patient data into a singlelocation and compartmentalizes that data into information packages so asto facilitate clinical decision making. In addition, the AWARE interfacefacilitates syndrome-related bundling of implementation by allowingphysicians to order and track relevant investigations and treatments inreal time at the bedside.

The AWARE system addresses a number of building blocks. First, thesystem uses data point utility in decision making (DUM) scores, wherebyclinical data is allocated a score based on its frequency of use inmedical decision making. DUM scores generally vary with clinicalcontext, such as prior medical history and ICU syndrome development(e.g. sepsis). DUM scores can be used to screen data points for theirlikely relevance to clinical decision making. Once known, the DUM scoreis incorporated into an algorithm which defines when and how that datapoint is displayed to the physician.

The AWARE system correlates a number of components to each other. First,the system employs “clinical information packages,” which are bundles ofrelated data that are recognizable as such to an experienced physician.Such packages may be formed by applying heuristic rules generated bysurveys of experienced caregivers or other observations of suchcaregivers. The surveys may seek to determine which data points thecaregivers address most often when encountering a patient in aparticular situation.

The packages can be organized by organ system, and the content can beinformed by context-specific DUM scores. The main components of thepackage include: (1) clinical contextual information (medicalbackground, admission diagnosis, acquired diagnosis); (2) currentphysiological status (heart rate, respiratory rate etc); (3) Current ICUsupports (fluid and pressor requirements, ventilator requirements etc);(4) relevant investigation results (ECG, Hb etc.); (5) relevantinvestigations status; and (6) relevant interventions status.

Second, the AWARE system uses “medical context search,” which searches,using key words, a patient's past medical history and problem list inthe patient's electronic medical record. The past medical historydefines one element of the clinical context in which data should beinterpreted. Once detected, the system defines when and how those keywords are presented to the physician.

Third, the AWARE system uses “organ failure awareness.” Acute illnessmanagement centrally involves the recognition and treatment of organfailures. A system may screen for the development of organ failures andmodify the content of clinical information packages accordingly. Thedetection of organ failures triggers modifications to the relevantclinical information packages. By expanding individual informationpackages in this fashion, the physician will have instant access toorgan specific data and increased awareness of the most vulnerable organsystems in individual patients. Early recognition of such organ failuresreduces the time to appropriate interventions and may alter patientoutcomes.

Fourth, the AWARE system includes “ICU syndrome awareness.” The earlyrecognition and treatment of syndromes such as sepsis is associated withimproved patient outcomes. Delayed recognition and treatment isassociated with poor outcomes. A system may screen for the potentialdevelopment of ICU syndromes such as shock and sepsis. The detection ofsuch syndromes can trigger the display of information packages relevantto the differential diagnosis and treatment of that particular syndrome.By presenting data in this fashion, the physician or other caregiver isimmediately alerted to the potential development of acute illnesssyndromes and can immediately implement appropriate therapies orinterventions.

Fifth, the AWARE system includes “treatment implementation awareness.”Once specific syndromes are identified, the status of each component ofmanagement of that syndrome can be displayed in the information packageformat. Compliance with the relevant components of management can thusbe displayed in real time. Once sepsis is diagnosed, for example, thestatus of relevant treatments (e.g., broad spectrum antibioticadministration, fluid resuscitation, pressor use), relevantinvestigations (e.g., blood cultures, SvO2, lactate, CBC/Hct, Type andscreen), and relevant targets (e.g., MAP>65 mmHg, antibiotic admin. <1hour, SvO2>70%) can be displayed in a Sepsis AWARE information package.

Sixth, the AWARE system provides for interacting with an AWARE interfacein a number of ways. For example, physicians may perform ordering fromwithin patient information packages by integrating the system with CPOEapplications. The results of investigations that carry a high DUM scorefor a particular clinical syndrome will be displayed within informationpackages. The status of the investigation will be indicated to thephysician. The status of investigations will include: not ordered,ordered but not done, done not available, and available. Evidence-basedinterventions will also be included in the syndrome specific informationpackage. The status of the intervention will include: not ordered,ordered not completed, and completed.

The physician may also be given the opportunity to trigger therecognition of syndromes or organ failures by inputting diagnosisdirectly into the bedside display. In this way, the clinician cantrigger the display of all relevant syndrome-specific informationpackages. By allowing a physician to interact in this way, the utilityof the AWARE display may be improved for the physician.

FIG. 1 is a conceptual flow diagram showing the processing ofpatient-related ICU information into a clinical decision to aid thepatient. At the top of the figure, a large plurality of data points areshown entering a box that represents a process for preparing data forhuman clinical decision making. The data points include a variety ofdata types, including real time information being read from the patient,such as oxygen levels, heart rate, and other similar factors. Inaddition, the data points can include information from an electronicmedical records system whose data is stored separate and distinct fromthe real time data, and can include factors such as laboratory resultsfor a patient. In addition, the data points can include more distantdata, such as data form the patient's medical history, which may beobtained from the electronic medical record system or from anothersource. The real time data, in one example, may be obtained from asystem that is local in the patient's room, while the electronic medicalrecord data may be obtained from a central system in a hospitalfacility, including from a centrally-located data stored that isaccessed over a network that can include the internet (using, forexample, well-known secure communication techniques).

The first component in the conceptual box is a filter. The filter mayserve to extract, from the large plurality of data points, particulardata points that are needed in the system. The filter may be providedwith particular fields in a system that are to be extracted from thevarious data stores (e.g., local real time data stores, electronicmedical record data store, etc.), and then request values for theparticular patient in those fields. The fields may be identified byheuristic rules that may implement preferences that have been determinedby surveys or other studies of experienced caregivers. For example,experienced caregivers may be asked to identify the data points thatthey consider during various patient care scenarios, and the data pointsfor those scenarios may be extracted using the filter. The filter maythen save the extracted values in its own data store, and may update theextracted values periodically. The periodicity may vary based on thedata store type, with updates from a real time data store occurring, forexample, on the order of every second, and updates from an electronicmedical record occurring on the order of minutes or more.

The filter may also be programmed to look for matches to certain valuesin the data store. In such a situation, the system may be more flexiblein that it may address multiple different systems without detailedprogramming to match the filter to the particular system. For example,the filter may extract electronic medical record data for a certainpatient based on a label for a field, without having to be previouslyprogrammed with the actual location for that field.

By this process, the filter may extract a subset of all the availabledata points in a system of stored patient data, according to data pointsthat have been determined to be of most interest to caregivers in aparticular field (e.g., ICU, etc.), at a particular job title level(e.g., attending physician, ICU nurse, etc.), and under a particular setof circumstances (e.g., patient undergoing organ failure). Theextraction process may narrow the information for presentation to alevel that is manageable and understandable to a typical caregiver.

Shown below the filter are a number of groups. The groups representcollections of data points that share a common characteristic. Forexample, the groups can be arranged according to organ or organfunction. Each member of a group can represent a particular patientvalues (e.g., pH, pulse rate, etc.) or a derivative value that isdetermined from one or more patient values. The members can also includeindications, such as indications that extreme values should be displayedin an emphasized manner, such as via a sound, a color (e.g., red forcritical), blinking, a larger font, or a bold font. Particular examplesof groupings or groups are discussed below.

The bottom component of the box is a presentation manager. Thepresentation manager provides for the manner in which the groups anddata points within the groups are to be displayed. The presentationmanager, for example, may determine textual labels and fonts forparticular data point values. The presentation manager may alsodetermine the relative positioning of groups and elements on a page, andthe positioning between pages where the system generates a multi-pageinterface. In addition, the presentation manager may generate icons orother graphics to present certain values, such as data point values. Forexample, a cardiac grouping may be represented by an icon of a heart,while a pulmonary grouping may be represented by an icon of a patient'slungs. Other graphical information, such as traces of graphs may also beemployed, and may be computed by a system from other values.

The output of the box may be a graphical display on a video monitor inthe proximity of a patient, which a caregiver may review, and preferablymay review quickly and effectively because an appropriate subset of datapoints is displayed, and is grouped and formatted in a convenient mannerfor the caregiver. Such output may readily lead to a caregiver making aquick and accurate clinical decision, such as by changing the medicationor other therapy provided to a patient, or by ordering that a particularprocedure or test be performed on a patient.

FIG. 2 is a block diagram showing various patient-related data sources.Each source may be in a separate and independent data stores. Sniffersmay include components that are training to extract data from othersources, such as particular admissions files, and other locations.Metadata includes data stores containing data about data in the rest ofthe system, such as dictionaries that describe the data that isavailable in a system.

Such dictionaries may be helpful to a caregiver who is designing acustom presentation for a monitor (where the custom presentation may betriggered whenever the caregiver's presence is detected near a monitor,as discussed with respect to FIG. 9 below). For example, caregivers mayuse touch screens and key board inputs to select data points that theyprefer to see in particular situations, and may then drag groups forthose indicators around a display using the touch screen input, and maydrag data points around inside each group, so as to produce a displaythat works best for the particular caregiver. A caregiver may also setup their screens more quickly by entering an identifier for anothercaregiver whose layouts they like, and those layouts may be appliedautomatically to the screens for the first caregiver.

Calculated values are stored in another data store or stores. The valuesmay take a variety of forms, including clinical reports on a patient.Also, hand entered data may also be accessed, and a variety ofelectronic medical record data may be separately accessed. The medicalrecord data may include lab results, clinical notes, nurse flow sheetdata, and the like.

FIGS. 3A to 3H show example displays that may be shown to caregivers inan ICU setting. FIG. 3A shows displays for multiple patients (which maybe displayed, for example, at a central station) and FIG. 3B shows adisplay for a particular patient.

The display in this example is divided into three zones: (1) clinicalinformation packages along the left side; (2) a syndrome detectionadvisory and physician interaction panel in the upper right, and (3) anorgan status summary display in the lower right.

In the left side of each of the information packages display, an organidentifier is shown (e.g., heart, lung, kidney, etc.). To the right ofthat is organ specific clinical contextual data, such as whether thepatient has a stent, hypertension, or other similar status. To the rightof and at the top of each package are shown current organ physiologicalstatus, such as heart rate and MAP for cardiac packages. Key data ineach of these packages are always displayed if available.

Below the current organ physiological status is current organ supportstatus such as Norepinephrine (NE) and dopamine levels. This area isdisplayed when organ failure is detected. To the right is the relevant(high DUM score) organ associated data, including data point identifier,status of Investigation/Intervention, and data point value. This area isdisplayed when organ failure or ICU syndrome is detected. The content ofthis area is determined by the context and is informed by the DUM scoredatabase. The physician may interact with this segment of the screen andorder investigations or interventions directly from here.

In the lower right corner of the screen, an organ status summary displayis provided. This section displays a summary of the current organstatus. In this version, the organ status is displayed based on SOFAscores. This is updated every 15 minutes in the present example. An XYplot of SOFA score (Y-axis) against Time (X-axis) can be accessed fromthis segment of the display. Such accessibility can enable the physicianto display the organ trajectory over time

FIGS. 3C to 3F shows a progression of displays that may be generated fora particular patient. In FIG. 3C, three areas are displayed and allfactors are relatively normal. The patient presents a number ofchallenges, in terms of hypertension, a stent, obesity, and a history ofsmoking. In FIG. 3D, several areas and data points have been highlightedto emphasize a changed that has occurred in the patient and the datapoints. Also, in the lower right corner of the display, the particulargroups of information being tracked by the system are shown as havingchanged status in some instances. In FIG. 3E, the patient is shown asbeing in shock. Such a display may be generated automatically, or byinput from a caregiver, such as the caregiver recognizing that thepatient is in shock, and providing a command to the system so thatinformation regarding parameters associated with shock may be displayed.In this display, syndrome detection advisory and provisions forphysician interaction are shown in the upper right corner of thedisplay. Such a display may be similar to a display like that shown inFIG. 3B. The upper right area, in this example, is active only when acritical illness syndrome is detected. The display includes an advisoryas to which primary (“SHOCK”) and secondary (“Possible Sepsis”) syndromeor syndromes have been detected. In addition, it contains a descriptionof which component of the syndrome has been detected as being present(e.g., “HR>90”). The physician may trigger the activation of thissection by inputting a diagnosis into the display. This will result in amodification to the AWARE display which presents syndrome specific datathat has high DUM scores.

FIG. 3F shows values for further progress with the patient during theepisode of shock. The status for CVS in the lower right has now shiftedinto a third status area.

FIG. 3G shows an organ failure detection screen area. Zone 1 is an organidentifier. Zone 2 shows organ failure detection rules (using SOFAscore). Zone 3 shows organ failure detection status from a DUM database.Zone 4 shows an organ failure score calculation, and zone 5 shows anorgan failure score (from SOFA scoring system).

FIG. 3H shows a syndrome detection screen area. Zone 1 shows a primarysyndrome detected, while zone 2 shows secondary syndrome identifiers.Zone 3 shows key components for recognition of the syndrome. Zone 4shows: (a) detection status (1=present, 0=not present); (b) secondaryrule used when combination of triggers are required to activate asyndrome advisory. Zone 5 shows the value to be displayed in associationwith a syndrome advisory. This notifies a physician of AWARE detectionof specific components of a syndrome. And zone 6 shows a syndromeadvisory. This notifies the physician which of the potential causes ofthe primary syndrome have been detected.

FIG. 4 is a flow chart showing actions for processing and presentingpatient-related ICU information. At a starting point, patient data isreceived. In ordinary operation, organ systems may be assigned fordisplay on a patient monitor, data for the patient can be assigned togroups formed in association with those systems, and currentphysiological data for the patient may be obtained, such as bymonitoring equipment proximate to the patient. Such data may then bedisplayed.

At a decision box, either organ failure or a syndrome are detected,either automatically, or from a physician detecting a syndrome andentering that observation into the system. The system engine may then bepopulated with data regarding data points determined by DUM to berelevant for the particular patient status. Data assignments may then bemade, and a system display may interact with a physician regardingfollow-up investigations, organ support status, and intervention. Also,a syndrome advisory generator may provide for a display of a syndromeadvisory to the caregiver. The caregiver may provide input back to thesystem with respect to things like syndrome specific interventions andinvestigations, such as via a CPOE interface to the system.

Certain surveys may be used to identify the data points that should bedisplayed to physicians for maximum effectiveness of a patientmonitoring system. For example, in a survey of 34 data points availableto physicians in an ICU, a median (IQR) of 11 (8-18) data points wereused by at least one of 60 surveyed physicians. Some data points wereused more frequently than others. (Chi-square 232, DF 33, p<0.0001). Thefollowing were in the top quartile of utilization: 402, RR, HR, MAP,DNR/DNI status, CXR changes, FiO2, respiratory support level and fluidbalance. Data points included in the bottom quartile included PaCO2,bilirubin, HCO3, glucose and base deficit.

FIG. 5 shows data from such a survey of physicians. Fifteen attendingintensivists were surveyed to judge which of a 35 point data set weremost clinically useful. The physicians were asked to agree or disagreewith the statement “this data point is useful when forming medicaljudgments about new ICU admissions.” Each data point was scored using aLikert scale: 1 (strongly disagree) to 5 (strongly agree). This scorewas termed the “data impact on medical judgment score” (DIM).Physician-provided DIM scores for all data points had a median (IQR)value of 4.41 (3.92-4.67). When DIM scores were categorized bydata-point or physician significant differences were found usingKruskal-Wallis test p<0.0001: Kruskal-Wallis statistic 142 and 106respectively. High mean DIM score suggests that caregivers common usethe points in the formation of medical judgments in an ICU. Variancebetween DIM data-point scores suggests that some of the included datapoints are less generally useful than others and that this issignificantly physician dependent.

This dataset was presented to all physician (attending andnon-attending) members of the admitting ICU team between 1.5-3 hours ofa new patient arrival. Subjects were asked to “identify those datapoints which you considered relevant for the diagnosis and management”of the newly admitted patient. The number of data points (out of the 33present on the clinical study questionnaire) used in decision making perphysician-patient interaction were calculated. The frequency with whichindividual data points were used by physicians in decision making wascalculated as a fraction of all captured physician-patient interactions.This score was termed the “data utilization in medical decision makingscore” (DUM). The methodology utilized to profile users' data needs isapplicable to any provider-task combination.

The top graph in FIG. 5 shows average physician ratings regarding therelevance of a number of data points that might be relevant tomonitoring and acting on the condition of a patient. The bottom leftgraph shows the number of data points that were used to treat any oneadmitted patient. As indicated, 218 physician questionnaires wereexamined to determine the frequency of data utilization per admission.Both attending and non-attending physician responses were included. Themedian (IQR) number of data points utilized were 9 (5-15). As shown, inalmost all cases, the number of data points used per admission were inthe single digits to teens.

The lower right graph introduces the concept of a Data Utilization inMedical decision making (DUM) score. The frequency distribution of DUMscores for 33 included admission data points are demonstrated in thegraph. DUM scores for each data point were calculated from the 218physician-patient admission interactions as follows: Sum of times datapoint utilized by physican/218. The median (IQR) of DUM scores were 0.29(0.21-0.38). The identification, by DUM score, of data points whichsubstantially contribute to medical decision making can be an importantfirst step in the redesign and rationalization of ICU data presentationformats.

Studies also indicate differences in the usage of data points to whichphysicians of varying experience or skill levels. FIG. 6 is a graphshowing differences between attending physicians and all other grades ofphysicians in terms of the data points to which they refer. To obtainthe data for the graph, a 34-point data-set was presented to allphysician members of an admitting ICU team within 2 hours of a newpatient's arrival. Physicians were asked to identify data points theyconsidered relevant for their initial diagnosis and management.Comparisons between attending and non-attending physician datautilization were made. Responses relating to 56 physician-patientinteractions were collected. Of 34 data points, a median (IQR) of 13.5(8-17) and 6 (3-9.75) were utilized by consultants (n=14) and all othergrades (n=40), respectively (Chi Square 6.7, p<0.001). Matched pairanalysis of individual data point utilization rates demonstrated a meandifference (95% C1) of −0.17 (−0.11 to −0.22), p<0.0001.

The graph thus shows some significant differences in data pointfrequency-of-utilization in admission decision making processes betweenphysician grades in the ICU. Attendings use a greater number of datapoints and do not place the same value on some laboratory data comparedto other grades of physician. These findings suggest that ICU expertsand non-experts do not share a view on the decision making value ofindividual patient data points. Identification of these differences maycontribute to the development of a rational patient-data presentationformat for use in the ICU. In addition, by characterizing expert definedhigh value data sets, physicians in training may gain insights intomodel decision making processes and contribute positively to theiracquisition.

FIG. 7 shows an example screen shot, or display, of a patient monitoringinteractive checklist. The particular display shown here is exemplaryonly, and particular arrangements, display decisions, and userinteractions should not be treated as limiting.

The checklist in the display of the figure presents a user interfacethat is populated with information about a patient and the patient'scondition that is automatically pulled from various sources, such as thepatient data 240 data store and data aggregation unit 228 of FIG. 2B,among others. The interface may be presented on a touch screen device sothat a caregiver can see the patient's condition and default settingsfor the system, and may choose to leave the settings alone or to changethem. Certain of the settings may affect the notification functionalityof the system discussed above. Also, certain entries on the interfacemay be written to the patient's chart and stored as part of thepatient's medical record. The association between the device thatprovides the interface and the particular patient may be made using avariety of known techniques, such as a caregiver log in (which mayinclude biometric identification) and identification of the patient,where the state of the system may be maintained (i.e., the patient orpatients who are associated with a terminal may be remembered by thesystem so that a caregiver may quickly access their data).

The display is broken visually into several sections to better guide acaregiver's attention as they review data from the display and perhapsenter data into the system, such as by directly onto a touch screenlayer over the display. For example, at the top of the display is agreeting that indicates the date and a patient name, along withintroductory text indicating the values below related to informationthat has been detected by the system.

Inside a visual box are three sections—a first section relating toventilation for the patient (here, a Mr. Jones), a second sectionrelating to intravenous (IV) treatment being provided to the patient,and a third relating to certain real time key conditions of the patient.Label 701 is a heading for the ventilated section, and is color coded toindicator a current status of the patient. If the ventilator mode is “noventilator” (“ ”) the indicator is colored red, or “Ventilator” (e.g.“BIPAP”) then it is green. As a secondary rule, if the indicator isgreen, then the ventilator checklist is displayed below the label (as isshown here). The displayed status is the most recent status for thepatient, and the status, in a particular example, is updated every twohours. Label 702 represents Head of Bed (HOB), which is alsocolor-coded—green if the HOB was 30 degrees or greater in the last 24hours, or else red. Such colors may be shown in the text of the labelitself and/or in indicator dots 714. If the color is green, then thesystem determines the percentage of time the HOB exceeded 30 degrees inthe prior 24 hours. The displayed value is the most recent value, andthe value is updated every four hours.

Label 703 represents the patient's ulcer prophylaxis, which represents(via searching a patient's electronic records) whether the patient hasreceived Omeprazole, Ranitidine, Lansoprazole, Famotidine, Pantoprazole,Cimetidine, Esomeprazole, Nizatidine, or Rabeprazole. If they havereceived any of these agents, the display shows the dosage and agentname, the administration schedule and administration schedule. If noneof these agents is found, then the display says “NONE.” The displayedvalues are from the last patient administration, and the values areupdated io every 24 hours. As shown, the data may be arranged in atemplate to provide for a natural language display rather than simplylabels with data. Also, indicator 715 shows green if any relevant agentshave been administered in the prior 24 hours, and red otherwise.

Label 704 represents deep venous thrombosis (DVT) prophylaxis, where thepatient's records are searched for the presence of, by Boolean rule(Heparin OR Argatroban SC/SQ or IVI OR enoxaparin and SC/SQ ORdalteparin and SC/SQ AND part string ‘SCD’ (where SCD=sequentialcompression device for DVT prophylaxis) from a patient database. Again,any detected agent is displayed, along with the dose, administrationschedule, administration time, and SCD. And again, the display may be ina natural language form, may show the last administration for thepatient, and may be updated every 24 hours. In addition, indicator 715shows green if any relevant agents have been administered in the prior12 hours, and red otherwise.

Label 705 represents whether the patient is receiving sedation. To makesuch a determination, the system searches intravenous infusion (IVI) foragents that are listed in CNS (Central Nervous System) support rules. Ifan active agent is detected,(any sedative IVI drug running in the past 4hours), the display shows the agent type and dose (e.g., in mcg/kg/min)and if no such agent is found, the display states “No IV sedationdetected in past 4 hours”. However, if a sedative agent is detected,then the display states “AGENT X discontinued at T=time.” This label isdisplayed actively (and for agents discontinued in last 24 hours), andis updated every 4 hours. An indicator of sedative or aggitative stateis given in the form of Richmond Agitation Sedation Score (RASS). Thecheckbox item (Selection 717), is predetermined as being appropriate(green) or inappropriate (red) by a secondary algorithm which combinesdata required for decision making. If a user disagrees with thegenerated result, they may select an alternative by any number ofinteractive gestures (click, point, touch).

Label 706 represents whether the patient has received a break fromsedation, where if an active agent has been running for more than 24hours, the system determines if there were any breaks greater than onehour in that time. If the agent has been running less than 24 hours,such a statement can be displayed, io whereas if it has been running formore than 24 hours with no detected breaks, the display may state “Nobreak in AGENT X detected in past 24 hours.” Under a secondary rule, ifa break is detected, then the display indicates the hours for the breakstart time and break end time. The display may be active and up-to-date,and may be updated regularly.

Label 707 represents whether the ventilator order is current—i.e.,whether an appropriate caregiver has ordered the use of a ventilator onthe patient within a prior time period that is consistent with normalstandards of care. In this area, at least four values can be displayed.The Mode indicates the mode of ventilation that is being delivered(here, IMV, for intermittent mandatory ventilation). The Rate representsthe number of inhalation and exhalation cycles per minute. The totalvolume (TV) is also shown in terms of ml per kg, where the patient'sweight is obtained from electronic medical records. The total volume iscomputed as TV=TV/PBW (predicted body weight) ml/kg. If the patient is amale, then PBW=50+0.91*(height (cm)-152.4). If the patient is a female,then PBW=45.5+0.91*(height(cm)-152.4). The positive end-expiratorypressure (PEEP) is also shown, and is expressed in terms of cm ofpressure. The checkbox item (Selection 718), is predetermined as beingappropriate (green) or inappropriate (red) by a secondary algorithmwhich combines data required for decision making. If a user disagreeswith the generated result, they may select an alternative by any numberof interactive gestures (click, point, touch).

Next, a question is posed regarding a respiratory weaning assessment. Ifthe caregiver makes a positive selection at 719, the system may gatherdata regarding the patient's medical history and respirator operationfor the patient, and may determine whether the patient is breathingsufficiently on their own so that they could be slowly weaned off therespirator.

Label 709 indicates a zone of the display in which the system indicateswhether any central IVI devices have been detected for the patient. Theinformation is displayed if any central venous line (CVL) is detected,and a corresponding text label is lit. The names, sites, and times ofinsertion for each of the IV's are also shown, and selection 720 showsred or green depending on how long it has been since the IV insertion.

Label 710 provides a name of the particular IV while label 711 indicatesthe site on the patient's body where the IV placed, and label 712indicates the insertion date for the particular IV. Finally, label 713represents the site condition (clean, red, inflamed, pus). Selection718—Using the information provided in 710-713, a determination may bemade (algorithm or provider) as to whether an individual CVL isnecessary for ongoing care (green) or should be removed (red). Theselection of red generates a “remove this line” order. The selection ofGreen generates a “necessary for ongoing care” order. The output of thissection is transmitted to a reporting database and is used by thehospital administration to generate reports for local, state andnational review

Finally, there are shown at the bottom of the display at indicators 521,patient information regarding the patient's white blood cell (WBC)count, body temperature, and microbiology, indicating the number ofactive microbiology reports available within the electronic healthrecord of the patient—the specifics of the reports are accessed directlyby clicking/touching this number and are displayed in a pop out window.Thus, in this manner, a caregiver can be provided with a masterchecklist that gathers various types of data about a patient andpresents the information in a convenient manner, by which a caregivermay set the system for operating a ventilations system or monitoringsuch a system and automatically generate data for a reporting database.

FIGS. 8A and 8B are two portions of a table of example values for thepatient monitoring interactive checklist of FIG. 7. Generally, each ofthe rows corresponds to one of the labels in FIG. 7. For each entry inthe table, a description is given, along with a main rule and asecondary rule that may be triggered based on the patient's data. Whatis displayed for each factor is also shown here, as is the time range(time Rg)

FIG. 9 is a block diagram of a patient monitoring system. The system 900may involve a number of networked computers and computer systems. Thesystem 900 is shown for convenience here as being centered around apatient monitor system 908. The patient monitor system 908 extracts datafrom a number of data stores 902-904 and groups and formats the data forconvenient display, such as in the manners io discussed above. The datastores 902-904 may include, for example, data reflecting real timeinformation about a patient (e.g., vital signs) as well as centrallystored electronic medical record information, among other things.Particular types of data are discussed with respect to FIG. 2 above.

A data extractor 910 may be programmed to identify and retrieve relevantdata form the data stores 902-904. The extractor 910 may be programmedto implement heuristic rules that were determined by observing orsurveying experienced caregivers with respect to the data points thatthey most often consult during particular phases of a patient's stay ina facility, such as in an ICU. A grouper 912 takes the particular datavalues retrieved by the extractor 910 and organizes the data intorelevant groups, such as by organ type as discussed above. The extractor910 or grouper 912 may also generate derivative data using one or moreextracted data points.

A display formatter 916 provides for the generation of data fordisplaying patient information. The display formatter 916 may, forexample, generate icons and arrange the icons and textual patientinformation provided by the extractor 910 and/or grouper 912 for displayon a patient monitor 918. The particular display may vary, in certainimplementations, based on the identity of the particular caregiver whois observing the monitor 918 or the class into which the caregiver falls(e.g., the caregivers particular job title, such as physician, nurse,attending physician, etc.).

The identity of the caregiver may be discerned by a caregiver identifier914 that is in communication with a sensor 920. The sensor 920 may takea variety of forms such as an RFID sensor that obtains identifyinginformation from an RFID chip in an identification badge worn by acaregiver when the caregiver is in proximity to the monitor 918 and thusin proximity to the sensor 920. The sensor 920 may also include abiometric sensor, such as a fingerprint reader. The caregiver mayprovide identifying information by other sensing mechanisms also, suchas logging into a clinical system in various familiar manners. Each ofthese sensed objects may be considered to be a beacon that providesidentifying information about the caregiver.

The identifying information may include an ID number such as form anRFID chip or bar code in or on an ID badge. The number may be returnedby the sensor, io and turned into a separate ID number by the caregiveridentifier 914, such as the caregiver's employee number. The displayformatter may then user the latter ID number to access a data store thatstores formatting information for a display that is unique to theparticular caregiver. The monitor 918 may thus, in this manner, providefor a display that is formatted in a manner that matches the job titleof the caregiver (attending physicians may need information that isslightly different than that needed by nurses) or matches the actualcaregiver (certain physicians may be more efficient if data is presentedto them in a customized manner).

FIG. 10 shows an example of a generic computer device 1000 and a genericmobile computer device 1050, which may be used with the techniquesdescribed here. Computing device 1000 is intended to represent variousforms of digital computers, such as laptops, desktops, workstations,personal digital assistants, servers, blade servers, mainframes, andother appropriate computers. Computing device 1050 is intended torepresent various forms of mobile devices, such as personal digitalassistants, cellular telephones, smartphones, and other similarcomputing devices. The components shown here, their connections andrelationships, and their functions, are meant to be exemplary only, andare not meant to limit implementations of the inventions describedand/or claimed in this document.

Computing device 1000 includes a processor 1002, memory 1004, a storagedevice 1006, a high-speed interface 1008 connecting to memory 1004 andhigh-speed expansion ports 1010, and a low speed interface 1012connecting to low speed bus 1014 and storage device 1006. Each of thecomponents 1002, 1004, 1006, 1008, 1010, and 1012, are interconnectedusing various busses, and may be mounted on a common motherboard or inother manners as appropriate. The processor 1002 can processinstructions for execution within the computing device 1000, includinginstructions stored in the memory 1004 or on the storage device 1006 todisplay graphical information for a GUI on an external input/outputdevice, such as display 1016 coupled to high speed interface 1008. Inother implementations, multiple processors and/or multiple buses may beused, as appropriate, along with multiple memories and types of memory.Also, multiple computing devices 1000 may be connected, with each deviceproviding portions of the necessary operations (e.g., as a io serverbank, a group of blade servers, or a multi-processor system).

The memory 1004 stores information within the computing device 1000. Inone implementation, the memory 1004 is a volatile memory unit or units.In another implementation, the memory 1004 is a non-volatile memory unitor units. The memory 1004 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 1006 is capable of providing mass storage for thecomputing device 1000. In one implementation, the storage device 1006may be or contain a computer-readable medium, such as a floppy diskdevice, a hard disk device, an optical disk device, or a tape device, aflash memory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 1004, the storage device1006, memory on processor 1002, or a propagated signal.

The high speed controller 1008 manages bandwidth-intensive operationsfor the computing device 1000, while the low speed controller 1012manages lower bandwidth-intensive operations. Such allocation offunctions is exemplary only. In one implementation, the high-speedcontroller 1008 is coupled to memory 1004, display 1016 (e.g., through agraphics processor or accelerator), and to high-speed expansion ports1010, which may accept various expansion cards (not shown). In theimplementation, low-speed controller 1012 is coupled to storage device1006 and low-speed expansion port 1014. The low-speed expansion port,which may include various communication ports (e.g., USB, Bluetooth,Ethernet, wireless Ethernet) may be coupled to one or more input/outputdevices, such as a keyboard, a pointing device, a scanner, or anetworking device such as a switch or router, e.g., through a networkadapter.

The computing device 1000 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 1020, or multiple times in a group of such servers. Itmay also be implemented io as part of a rack server system 1024. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 1022. Alternatively, components from computing device 1000 maybe combined with other components in a mobile device (not shown), suchas device 1050. Each of such devices may contain one or more ofcomputing device 1000, 1050, and an entire system may be made up ofmultiple computing devices 1000, 1050 communicating with each other.

Computing device 1050 includes a processor 1052, memory 1064, aninput/output device such as a display 1054, a communication interface1066, and a transceiver 1068, among other components. The device 1050may also be provided with a storage device, such as a microdrive orother device, to provide additional storage. Each of the components1050, 1052, 1064, 1054, 1066, and 1068, are interconnected using variousbuses, and several of the components may be mounted on a commonmotherboard or in other manners as appropriate.

The processor 1052 can execute instructions within the computing device1050, including instructions stored in the memory 1064. The processormay be implemented as a chipset of chips that include separate andmultiple analog and digital processors. The processor may provide, forexample, for coordination of the other components of the device 1050,such as control of user interfaces, applications run by device 1050, andwireless communication by device 1050.

Processor 1052 may communicate with a user through control interface1058 and display interface 1056 coupled to a display 1054. The display1054 may be, for example, a TFT LCD (Thin-Film-Transistor Liquid CrystalDisplay) or an OLED (Organic Light Emitting Diode) display, or otherappropriate display technology. The display interface 1056 may compriseappropriate circuitry for driving the display 1054 to present graphicaland other information to a user. The control interface 1058 may receivecommands from a user and convert them for submission to the processor1052. In addition, an external interface 1062 may be provide incommunication with processor 1052, so as to enable near areacommunication of device 1050 with other devices. External interface 1062may provide, for example, for wired communication in someimplementations, or for wireless communication in other implementations,and multiple interfaces may also be used.

The memory 1064 stores information within the computing device 1050. Thememory 1064 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 1074 may also be provided andconnected to device 1050 through expansion interface 1072, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 1074 may provide extra storage spacefor device 1050, or may also store applications or other information fordevice 1050. Specifically, expansion memory 1074 may includeinstructions to carry out or supplement the processes described above,and may include secure information also. Thus, for example, expansionmemory 1074 may be provide as a security module for device 1050, and maybe programmed with instructions that permit secure use of device 1050.In addition, secure applications may be provided via the SIMM cards,along with additional information, such as placing identifyinginformation on the SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 1064, expansionmemory 1074, memory on processor 1052, or a propagated signal that maybe received, for example, over transceiver 1068 or external interface1062.

Device 1050 may communicate wirelessly through communication interface1066, which may include digital signal processing circuitry wherenecessary. Communication interface 1066 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 1068. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 1070 mayprovide additional navigation- and location-related wireless data todevice 1050, which io may be used as appropriate by applications runningon device 1050.

Device 1050 may also communicate audibly using audio codec 1060, whichmay receive spoken information from a user and convert it to usabledigital information. Audio codec 1060 may likewise generate audiblesound for a user, such as through a speaker, e.g., in a handset ofdevice 1050. Such sound may include sound from voice telephone calls,may include recorded sound (e.g., voice messages, music files, etc.) andmay also include sound generated by applications operating on device1050.

The computing device 1050 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 1080. It may also be implemented as part of asmartphone 1082, personal digital assistant, or other similar mobiledevice.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), and theInternet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the invention. For example, much of thisdocument has been described with respect to ICU monitoring withattending physicians, but other forms of patient monitoring andreporting may also be addressed.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, io other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A computer-implemented method for treating acritical-care patient under the care of a caregiver at a healthcarefacility, the method comprising: monitoring the patient with real-timemonitoring equipment that captures physiological data corresponding toactual physical patient condition at time of capture, and storingcaptured physiological data in a real-time data store; accessing anelectronic medical record data store that stores medical history of thepatient; extracting, from a larger set of available data about thepatient in both the real-time data store and the electronic medicalrecord data store, a data subset, wherein the data subset is extractedbased on a determination of relevance relative to a stored score thataggregates results from submitting to multiple caregivers questionsregarding importance placed on particular parameters in treatingpatients and receiving answers to the questions from the multiplecaregivers; analyzing the extracted data subset to determine whether oneor more indicia of organ failure are present; grouping data within theextracted subset by its relationship to organ or organ function of thepatient, and displaying the grouped data within an interactive displayproximate the patient; periodically repeating the monitoring, accessing,extracting, analyzing, grouping and displaying steps; upon determinationthat one or more indicia of organ failure are present, displaying thegrouped data differently than previously displayed, to provide targetedinformation corresponding to identified organ failure, and to deprecateother previously displayed information; in response to providing thetargeted information, receiving input, through the interactive display,from the caregiver, to order a procedure or change a therapy; and basedon the received input, ordering the procedure or logging the change intherapy through an integrated computerized physician order entry system.2. The computer-implemented method of claim 1, wherein analyzing theextracted data subset comprises determining whether a lactatemeasurement is lower or higher than a threshold associated with thestored score.
 3. The computer-implemented method of claim 2, furthercomprising determining that the lactate measurement is 2.8 mmol/L orgreater.
 4. The computer-implemented method of claim 1, whereinanalyzing the extracted data subset comprises determining whether meanarterial blood pressure, dopamine, a ratio of norepinephrine toepinephrine, and a ratio of epinephrine to norepinephrine are higher orlower than thresholds associated with the stored score.
 5. Thecomputer-implemented method of claim 4, further comprising determiningthat mean arterial blood pressure is less than 70 mmHG and a dopaminemeasurement is greater than 5 ng/mL.
 6. The computer-implemented methodof claim 4, further comprising determining that mean arterial bloodpressure is less than 70 mmHG, a dopamine measurement is between 5 and15 ng/mL, and a ratio of norepinephrine to epinephrine is between 0 and0.1.
 7. The computer-implemented method of claim 4, further comprisingdetermining that mean arterial blood pressure is less than 70 mmHG, adopamine measurement is greater than 15 ng/mL, and a ratio ofepinephrine to norepinephrine is greater than 0.1.
 8. Thecomputer-implemented method of claim 1, wherein analyzing the extracteddata subset comprises determining whether an ST segment ofcardiovascular sinus rhythm or levels of troponin have changed relativeto thresholds associated with the stored score.
 9. Thecomputer-implemented method of claim 8, further comprising detecting achange in the ST segment and a rise in troponin of 0.06 ng/mL.
 10. Thecomputer-implemented method of claim 1, wherein analyzing the extracteddata subset comprises comparing urine output, creatine levels, and fluidbalance to thresholds associated with the stored score.
 11. Thecomputer-implemented method of claim 10, further comprising analyzingthe extracted data relative to a fluid bolus whose administration to thepatient was stored in the electronic medical record data store.
 12. Thecomputer-implemented method of claim 1, wherein periodically repeatingthe monitoring, accessing, extracting, analyzing, grouping anddisplaying steps comprises at least one of capturing updatedphysiological data on the order of every second, accessing theelectronic medical record data store to identify updates on the order ofevery few minutes, accessing the electronic medical record data store toidentify updates on the order of every two to four hours, and displayingan updated organ status every 15 minutes.
 13. The computer-implementedmethod of claim 1, further comprising identifying a plurality of subsetgroups of parameters, wherein each of the plurality of subset groups isdirected to a particular caregiver level that differs from others of theplurality of subset groups.
 14. The computer-implemented method of claim13, further comprising detecting a presence of an electronic caregiverbeacon in proximity to the interactive display, determining a caregiverlevel corresponding to a caregiver associated with the beacon, anddisplaying a subset of parameters directed to the determined caregiverlevel.
 15. The computer-implemented method of claim 1, wherein thedisplaying occurs in an organ status summary area of a visual display,and the method further comprises: displaying a clinical informationpackage in another area of the visual display that displays differentparameter values for different organs or organ groups with a graphicidentifying each particular organ or organ group, and a syndromedetection advisor in another area of the visual display that lists aplurality of medical syndromes for the patient and statuses of each ofthe plurality of medical syndromes.
 16. A computer-implemented methodfor treating a critical-care patient under the care of a caregiver at ahealthcare facility, the method comprising: monitoring the patient withreal-time monitoring equipment that captures physiological datacorresponding to actual physical patient condition at time of capture,and storing captured physiological data in a real-time data store;accessing an electronic medical record data store that stores medicalhistory of the patient; extracting, from a larger set of available dataabout the patient in both the real-time data store and the electronicmedical record data store, a data subset, wherein the data subset isextracted based on application of fixed heuristic rules that implementpreferences of experienced caregivers who have been surveyed to identifydata points most frequently consulted for various patient carescenarios; analyzing the extracted data subset to determine whether oneor more indicia of organ failure are present; grouping data within theextracted subset by its relationship to organ or organ function of thepatient, and displaying the grouped data within an interactive displayproximate the patient; periodically repeating the monitoring, accessing,extracting, analyzing, grouping and displaying steps; upon determinationthat one or more indicia of organ failure are present, displaying thegrouped data differently than previously displayed, to provide targetedinformation corresponding to identified organ failure, and to deprecateother previously displayed information; in response to providing thetargeted information, receiving input, through the interactive display,from the caregiver, to order a procedure or change a therapy; and basedon the received input, ordering the procedure or logging the change intherapy through an integrated computerized physician order entry system.17. The computer-implemented method of claim 16, wherein analyzing theextracted data subset comprises determining whether a lactatemeasurement is lower or higher than a threshold associated with thefixed heuristic rules.
 18. The computer-implemented method of claim 16,wherein analyzing the extracted data subset comprises determiningwhether mean arterial blood pressure, dopamine, a ratio ofnorepinephrine to epinephrine, and a ratio of epinephrine tonorepinephrine are higher or lower than thresholds associated with thefixed heuristic rules.
 19. The computer-implemented method of claim 16,wherein analyzing the extracted data subset comprises determiningwhether an ST segment of cardiovascular sinus rhythm or levels oftroponin have changed relative to thresholds associated with the fixedheuristic rules.
 20. The computer-implemented method of claim 16,wherein analyzing the extracted data subset comprises comparing urineoutput, creatine levels, and fluid balance to thresholds associated withthe fixed heuristic rules.